Recent advances in vehicle technology, from self-driving cars to autonomous drones and similar vehicles, the security and safety for these vehicles have taken the center stage. These vehicles are operated under tight control of Electronic Control Units (ECUs) which uses sensors and activators to monitor and to control numerous operations taking place as part of the vehicle's smooth operation. Such ECUs normally are driven by multi-millions lines of code designed to derive actuators that help carry out a wide range of tasks such as unlocking the vehicle door, adjusting throttle valve opening, applying breaks, steering self-driving vehicles, communicating with external networks, etc. Interconnecting all ECUs, all the sensors, and all the actuators, requires an insane number of wires rendering direct interconnection unrealistic.
To reduce the amount of wiring the vehicles designers rely on using various communication buses such as Controller Area Network (CAN) bus. However, CAN bus lacks most provisions needed to address the newly found security issues which were unknown to the standard body who originally defined the bus. In addition, the digital information exchanged between various ECUs and between the vehicles' gateways with outside-world, could be prone to hacking attacks and malicious interventions. As an example, research has demonstrated how one could inject false traffic information into the vehicle navigation system utilizing Radio Data System, and Traffic Message Channel.
Should an attacker or a hacker access and control the ECU assigned to critical operation of the vehicle, it can create havoc and compromise the safety of the hacked vehicle, other vehicles, and their occupants. As such vehicle manufactures employ a variety of techniques to deter hacking into the vehicle. As an example, one modern anti-theft system, which is popular among vehicle manufactures, is to use a cryptographic protocol such as challenge-response onboard the vehicle. The vehicle first generates a pseudorandom number (challenge) which requires to be authenticated by the remote unit. The remote unit in response calculates the next code in the sequence and sends it back (response) to be checked by the vehicle for correctness. The scheme relies on the fact that the procedure for generating the pseudorandom number is secret and each invocation would bring about an unpredictable number. However, it was shown how a side channel attack could successfully sniff out the master key for the random number generator thus allowing an attacker to access every vehicle that uses this algorithm.
Other hacker have been able to demonstrate how easy it is to circumvent the CAN bus by injecting malicious code into the bus system, either through the diagnostic channel, or through the entertainment system to falsely force an ECU to take dangerous decisions (such as applying a sharp turn when the vehicle is moving, or exceedingly speeding or unnecessarily breaking). The CAN bus has been widely used across the industry but has the major drawback that it has no protocol to provide a measure of authenticity. Not only the CAN bus messages lack the feature of identifying a sender or a receiver of a message, if receiving node is not configured to receive a particular type of message, it will ignore all these types of messages. In fact, some researchers have demonstrated that they could remotely get some malicious code to be executed on a vehicle using either mp3 radio parser, Bluetooth, or via telematic units. Once the research team was able to make the code running on the vehicle, the resarchers could then inject CAN messages which adversely affected the performance of the vehicle.
U.S. Pat. No. 7,734,046 issued to Volker Urban et al., describes an authentication method between a vehicle transponder device and a reader device containing a microprocessor wherein the transponder controls certain functions of the vehicle. The process of authentication starts with the microprocessor sending a random number RN1, along with an encryption of the random number F(RN1) to the transponder. The transponder generates its own encrypted version of the random number which is compared to the one sent by the microprocessor to decide whether or not to send an ACK or NACK signal back to the processor for confirming or denying the initial transaction between the two devices. The transponder also creates a new encryption of the random number G(RN1) which is sent back to the microprocessor. The microprocessor device then decrypts the new function G(RN1) to check the validity of the encryption by the transducer.
The problem with the above disclosure is that the encryption keys used are stored onboard memory devices for both the microprocessor and the transponder and thus can be detected easily by someone skilled in the art. Furthermore, both the encryption and decryption algorithm used in the reader device are software-based running on the microprocessor device for which the corresponding code not only is susceptible to hacking, it is also rather slow. Finally, the amount of information that are transmitted back and forth between the transponder and the microprocessor is not practical.
U.S. Pat. No. 7,231,041 issued to Thomas M. Forest et al., describes how a key fob device could be used to instruct a receiver device to lock or unlock a door to a vehicle. A secrete key shared between the two devices, along with a “key generator” circuit, is used to encrypt a nonvolatile counter by the key fob device to generate a “working key” which is then transmitted to the receiver device during a “training session” for all future communications. When the key fob sends an encrypted command using the “working key” to the receiver device, the latter decrypts the command using the same “working key” and compares it against expected values before trying to implement the command. The “working key” will be different in each invocation, due to a counter from a non-volatile device.
The problem with the above disclosure is that the nonvolatile counter is not an integral part of encryption engine. As such, one could put the key fob device in training mode while replacing the nonvolatile counter with a fake one causing the same “working key” to be sent to the receiver device. Furthermore, it is not clear how the unique generating key that is programmed into a key fob at the factory related to a particular vehicle and how the “receiver” would associate that particular key fob with the vehicle. This important missing information allows any key fob to open or to close the door of any vehicle using the above disclosure.
U.S. Pat. No. 7,034,654 issued to Thomas M. Forest et al., describes a challenge/response scenario between an Engine Immobilizer Unit (EIU) and a vehicle Electronic Control Unit (ECU) as an engine immobilizer security system. Both ECU and EIU use the same secrete encryption key for communication between the two units. The ECU sends a randomized challenge to the EIU, which would be encrypted as a response and be sent back to the ECU. The ECU uses the same key and encryption circuit to encrypt the challenge and compares the encrypted challenge to the response. If the response matches the encrypted challenge, engine operation is enabled.
The problem with the above disclosure once again lies with the fact that the EIU has no particular association with a given ECU. As such, any EIU which shares the same encryption key as the ECU, would be able to respond correctly to a challenge from the ECU and thus igniting the engine. Also, if ECU uses software to preform encryption, that would be prone to hacking.
U.S. Pat. No. 5,600,723 issued to Phillip J. Woodall et al., uses a fuel pump unit to authenticate an inserted ignition key into the vehicle lock to allow operation of the vehicle. Both vehicle serial number and the ignition key serial number are stored on memories in the fuel pump unit as well as on the ignition key. An encryption scheme on the fuel pump unit is used to encrypt the vehicle serial number which is sent to the ignition key. The ignition key decrypts the received information using the same vehicle serial number to recover the random number. The encryption engine on the ignition key then encrypts the key serial number on the ignition key using the random number and sends that back to fuel pump unit. The fuel pump unit decrypts the encrypted information and recovers the key serial number which is then compared with the key serial number stored in the memory of fuel pump to authorize the engine ignition.
The problem with the above disclosure is that at least two encryption and two decryption operations are required, each with a different serial number to make the scheme work and thus it would be slow and not cost effective. More importantly both vehicle serial number and ignition key serial number are stored on distinct memory modules onboard the ignition key. The distinct memories are relatively easy to hack and access their content; an intruder can easily read the memories onboard the ignition key and make a legitimate key from a blank ignition key and steal the vehicle.